Method and system for handling HARQ operations during transmission mode changes

ABSTRACT

A method and device for handling hybrid automatic repeat request (‘HARQ’) operations during transmission mode changes, the method detecting a transmission mode change; and manipulating an HARQ process buffer based on the detecting. Further, a method and network element for handling hybrid automatic repeat request (‘HARQ’) operations during transmission mode changes, the method checking when a user equipment is in a transmission mode uncertainty window; and blocking communications to the user equipment or utilizing a downlink control information format 1A for communications to the user equipment.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation reissue of U.S. application Ser. No.14/933,789, filed Nov. 5, 2015, which is a reissue of U.S. Pat. No.8,578,233, which is a continuation of U.S. application Ser. No.12/538,016 which was filed on Aug. 7, 2009 and which is entirelyincorporated by reference herein.

FIELD OF THE DISCLOSURE

The present disclosure relates to HARQ operations and in particular toHARQ operations during transmission mode changes.

BACKGROUND

Long Term Evolution (LTE), or Evolved Universal Terrestrial Radio Access(E-UTRA) is a radio technology that is evolving to permit multiplesimultaneous transport blocks under various transmission modes. Thus, anE-UTRAN Node B (eNB) can, in certain transmission modes, send multipletransport blocks within the same subframe or transmission opportunity toa user equipment (UE).

The transition from one transmission mode to another may result dataloss or other issues on a UE. In particular, a Hybrid Automatic RepeatRequest (HARQ) scheme at the receiver maintains a soft combining bufferfor each HARQ process.

Furthermore, the E-UTRA radio resource control (RRC) does not providefor an exact activation time during reconfiguration procedures. If a newmode of downlink transmission is applied by an eNB earlier than the timewhen a user equipment (UE) completes reconfiguration, reception of databy the UE may fail. Similarly, if the old downlink transmission modecontinues to be applied by the eNB after the time when the UE completesreconfiguration, reception of the data by the UE may also fail.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will be better understood with reference to thedrawings in which:

FIG. 1 is a block diagram showing downlink HARQ processes with one andtwo transport blocks;

FIG. 2 is a flowchart showing a procedure for flushing HARQ soft bufferson a transmission mode change;

FIG. 3 is a flowchart showing a procedure for flushing HARQ soft buffersif a transmission mode change occurs in which the maximum number oftransport blocks changes;

FIG. 4 is a flowchart showing a procedure for flushing buffers ontransmission mode change with retention of soft bits when transitioningfrom a mode with two transport blocks to a mode with one transportblock;

FIG. 4A is a flowchart showing a procedure for flushing buffers on achange from a mode with one transport block to a mode with two transportblocks.

FIG. 4B is a flowchart showing a procedure for discarding soft bufferbits on a transition from a mode with two transport blocks to a modewith one transport block.

FIG. 5 is a flowchart showing a procedure for flushing buffers ontransmission mode change with retention of a second transport block'ssoft bits when transitioning from a mode with two transport blocks to amode with one transport block;

FIG. 5A is a flowchart showing a procedure for retention of a secondtransport block's soft bits when transitioning from a mode with twotransport blocks to a mode with one transport block;

FIG. 6 is a block diagram showing the retention of used soft bits ontransition from a mode with two transport blocks to a mode with onetransport block;

FIG. 7 is a block diagram showing the retention of used soft bits ontransition from a mode with one transport block to a mode with twotransport blocks;

FIG. 8 is a flowchart showing the retention of used soft bits ontransition between transmission modes with different numbers oftransport blocks;

FIG. 8A is a flowchart showing the retention of used soft bits ontransition between transmission modes with different numbers oftransport blocks;

FIG. 9 is a timing diagram showing DCI formats used during transitioningbetween transport modes;

FIG. 10 is a flowchart showing the use of DCI format 1A or the blockingof transmission during an uncertainty window;

FIG. 11 is a block diagram showing truncation of parity bits for a largetransport block;

FIG. 12 is a block diagram showing the expansion of a transport blockwhen transitioning from a mode with two transport blocks to a mode withone transport block;

FIG. 13 is a block diagram showing the truncation of a transport blockwhen transitioning from a mode with one transport block to a mode withtwo transport blocks; and

FIG. 14 is a block diagram of an exemplary user equipment.

DETAILED DESCRIPTION

The present disclosure is described below with regard to examples fordownlink HARQ processes in Release 8 of E-UTRA (also known as Long TermEvolution (LTE)). This is, however, not meant to be limiting, and insome cases the methods and systems applied can be also utilized withuplink HARQ processes, for example in future E-UTRA releases. Inparticular, Long Term Evolution Advanced (LTE-A) may use Multiple InputMultiple Output (MIMO) for uplink transmissions and in this case themethods and systems of the present disclosure may be utilized for uplinkas well as downlink processes.

Furthermore, the examples below are only meant to be illustrative of thevaried methods and systems, and could be modified by those skilled inthe art and still be within the scope of the present disclosure. Inparticular, the present disclosure could be applied to radio networkshaving more or less than seven transmission modes, to scenarios wheremore than two transport blocks are permitted in a single subframe, amongother variations.

Downlink Transmission Modes

In E-UTRA (LTE) Release 8, seven downlink transmission modes have beendefined in the 3^(rd) Generation Partnership Project (3GPP) TechnicalSpecification (TS) 36.213, “Technical Specification Group Radio AccessNetwork; Evolved Universal Terrestrial Radio Access (E-UTRA); PhysicalLayer Procedures (Release 8)”, version 8.7.0 2009-06, the contents ofwhich are incorporated herein by reference.

Table 7.1-5 of this reference is shown below as Table 1.

TABLE 1 Downlink transmission modes for LTE Transmission modeTransmission scheme of PDSCH 1 Single antenna port, port 0 2 Transmitdiversity 3 Transmit diversity if the associated rank indicator is 1;Otherwise large delay CDD 4 Closed-loop spatial multiplexing 5Multi-user MIMO 6 Closed-loop spatial multiplexing with a singletransmission layer 7 If the number of PBCH antenna ports is one, singleantenna port, port 0; Transmit diversity; Single antenna port; port 5(beamforming)

As seen from Table 1 above, seven transmission modes are defined.Transmission modes 1, 2, 5, 6 and 7 all utilize a single transport blockper subframe (or downlink HARQ process) whereas transmission modes 3 and4 may utilize 2 transport blocks.

The default transmission mode is transmission mode 1 or 2, depending onthe number of physical broadcast channel (PBCH) antenna ports, asdefined in Section 9.2.4 of the Technical Specification 36.331, “ThirdGeneration Partnership Project; Technical Specification Group RadioAccess Network; Evolved Universal Terrestrial Radio Access (E-UTRA);Radio Resource Control (RRC); Protocol Specification (Release 8)”,version 8.6.0, 2009-06, the contents of which are incorporated herein byreference. The eNB may reconfigure the transmission mode for aparticular UE in order to use a more efficient transmission mode or amore robust transmission mode. Examples of more efficient transmissionmodes may include closed-loop spatial multiplexing in a good radioenvironment. Examples of a robust transmission mode may include transmitdiversity in unfavorable radio conditions.

A reconfiguration from one transmission mode to another is signaledthrough radio resource control protocols, using the AntennaInfoinformation element within the PhysicalConfigDedicated informationelement, as defined in Section 6.3.2 of the 3GPP TS 36.331 reference.

Under current E-UTRA specifications, when transmission modes 3 or 4 areconfigured, the eNB may transmit up to two transport blocks to a UE in asingle subframe. In the remaining transmission modes, the eNB maytransmit a maximum of one transport block to a UE in a given subframe.All of the UE-specific transport blocks for a given subframe areassociated with the same downlink HARQ process.

Transmission Mode Reconfiguration

The transmission mode reconfiguration procedure is described as part ofthe physical channel reconfiguration procedure in Section 5.3.10.6 ofthe 3GPP TS 36.331 specification. Currently the technical standardreads:

5.3.10.6 Physical Channel Reconfiguration

The UE shall:

-   -   1> reconfigure the physical channel configuration in accordance        with the received physicalConfigDedicated;    -   1> if the antennaInfo is included and set to ‘explicit Value’:        -   2> if the configured transmissionMode is not ‘tm3’ or ‘tm4’            release ri-ConfigIndex in cqi-ReportPeriodic, if previously            configured;    -   1> else if the antennaInfo is included and set to        ‘defaultValue’:        -   2> release ri-ConfigIndex in cqi-ReportPeriodic, if            previously configured;

Furthermore, Section 11.2 of the 3GPP TS 36.331 specification requiresthat the UE complete a radio resource configuration, which may include atransmission mode reconfiguration, within 15 milliseconds, measured fromthe subframe at which the transport block containing the reconfigurationcommand was successfully received by the UE. The UE should be ready totransmit the RRC acknowledgement message that the radio resourcereconfiguration has been completed no later than this 15 millisecondbound. However, in some cases additional time may be required for actualtransmission and possible HARQ retransmission of the RRC acknowledgementmessage on the uplink.

Typically, the eNB would be able to determine with a reasonable level ofconfidence that the UE has received the transport block containing theRRC reconfiguration command from downlink HARQ acknowledgement ornegative acknowledgement (ACK/NACK) feedback. However, there is a smallprobability of a NACK to ACK error on the uplink, where the eNB wouldinitially think that the UE has received the RRC reconfiguration commandwhen in fact the UE has not been able to successfully decode thecorresponding transport block. Hence, the eNB cannot be completely surethat the UE has actually applied the transmission mode change until theeNB receives the RRC reconfiguration acknowledgement.

As will be appreciated, physical layer reconfigurations may be ratherfrequent. Furthermore, such transmission mode reconfigurations may occurin various situations, including but not limited to:

-   -   at initial RRC connection (or re-establishment), where the        default transmission mode is first used and the UE needs to be        moved to a MIMO mode;    -   following inter-cell handover when the channel conditions in the        new cell are not yet fully known;    -   switching between line-of-sight and non-line-of-sight        environments. This may occur, for example, in dense urban        environments; and    -   switching between different discontinuous reception (DRX) cycle        lengths, thereby causing variations in the channel quality        indicator (CQI) reporting rate and thus changes in the optimal        MIMO mode.

Downlink HARQ Soft Buffers

For HARQ, each received coded bit is assigned a soft value. The softvalues are typically represented with a fixed point number within anactual implementation. For example, a soft value using 5 bits ofprecision may be between negative fifteen and positive fifteen to definea bit that has been received. In this case, the sign may be used toindicate what the receiver hypothesizes that the bit is, where (forexample) a negative sign may represent a bit value of zero and apositive sign may represent a bit value of one, and the magnitude is thelevel of confidence that the receiver has with regard to the value.Thus, a plus fifteen may show that the receiver is fairly sure that abit value of “one” was received, whereas a negative fifteen may indicatethat the receiver is fairly sure that a bit value of “zero” wasreceived. Conversely, a fixed point number of “+1” may indicate that thereceiver thinks that a bit value of 1 was received, but is not verysure. These soft bit values are then used as the input to FEC (ForwardError Correction) decoding (e.g. a turbo decoder), although anyjust-received soft bit values may first be combined with otherpreviously stored/buffered soft bit values prior to FEC decoding.

For soft combining purposes, each of the available downlink HARQprocesses maintains a soft combining buffer. The size of the buffer isdefined in terms of the number of soft channel bits, where each soft bitrepresents a numerical value such as a Log Likelihood Ratio (LLR) usedfor Forward Error Correction (FEC) decoding purposes. As would beappreciated by those in the art, each soft bit value may actuallyrequire several bits of physical memory storage.

In LTE, a total number of soft channel bits for all downlink HARQprocesses is defined in terms of the UE category. This is shown belowwith regard to Table 2, which is a representation of Table 4.1-1 of 3GPPTS 36.306, version 8.4.0, 2009-06, the contents of which areincorporated herein by reference.

As indicated in Table 2 below, each UE category has a maximum number ofdownlink shared channel (DL-SCH) transport block bits received within aTTI (Transmission Time Interval). As used in the present disclosure(i.e. referring to DL-SCH transport blocks carried on the PDSCH(Physical Downlink Shared CHannel) and/or to UL-SCH (Uplink SharedCHannel) transport blocks carried on the PUSCH (Physical Uplink SharedCHannel)), one TTI can be considered to be equivalent to one subframe,and may also be referred to as one transmission opportunity. In thecontext of E-UTRA, therefore, one transmission opportunity refers to atransmission unit of time equal to one subframe, which may have a lengthof 1 ms.

The fourth column of Table 2 indicates the total soft buffer size acrossall HARQ processes. For example, with frequency division duplexing(FDD), eight HARQ processes may be defined. Thus the total number ofsoft channel bits is the total for all of the HARQ processes.

TABLE 2 Downlink physical layer parameter values set by the fieldue-Category Maximum Maximum Maximum number of number of DL- number ofbits Total supported SCH transport of a DL-SCH number layers for blockbits transport of soft spatial UE received block received channelmultiplexing Category within a TTI within a TTI bits in DL 1 10296 10296250368 1 2 51024 51024 1237248 2 3 102048 75376 1237248 2 4 150752 753761827072 2 5 299552 149776 3667200 4

The following equation, taken from Section 5.1.4.1.2 of 3GPP TS 36.212,version 8.7.0, 2009-06, the contents of which are incorporated herein byreference, gives the soft buffer size for a transport block as:

$\begin{matrix}{N_{IR} = \left\lfloor \frac{N_{soft}}{K_{MIMO} \cdot {\min\left( {M_{DL\_ HARQ},M_{limit}} \right)}} \right\rfloor} & \left( {{Equation}\mspace{14mu} 1} \right)\end{matrix}$

-   -   where N_(IR) is the number of incremental redundancy bits (i.e.        the soft buffer size for one individual transport block);    -   N_(soft) is the total number of soft channel bits as provided in        Table 2 above;    -   K_(MIMO) is equal to 2 if the UE is configured to receive        physical downlink shared channel (PDSCH) transmissions based on        transmission modes 3 or 4, or equal to 1 otherwise;    -   M_(DL) _(_) _(HARQ) is the maximum number of downlink HARQ        processes which is fixed as 8 for frequency division duplexing        but may be variable for time division duplexing;    -   M_(limit) is a constant and is equal to 8.

Equation 1 provides that the available soft bit memory is dividedequally among the transport blocks that may be contained with a downlinkHARQ process. In other words, the memory is divided equally among thedownlink HARQ processes. Furthermore, when a transmission modepotentially utilizes two transport blocks per subframe such as intransmission modes 3 or 4, the amount of soft bit memory per transportblock is half of what it would be for the other transmission modes. Thatis, the total memory allocated per downlink HARQ process is eitheroccupied by one transport block for transmission modes 1, 2, 5, 6 or 7,or divided equally between two transport blocks for transmission modes 3and 4, regardless of the actual sizes of the individual transport blocksthat may be stored in these buffers.

Referring to FIG. 1, FIG. 1 shows the buffer for a downlink HARQ processhaving a single transport block and also the buffer for a downlink HARQprocess having two transport blocks. The total memory size for each ofthese two downlink HARQ processes is the same.

In particular, the downlink HARQ process in transmission mode 1, 2, 5, 6or 7 is shown as DL (downlink) HARQ process 110, whereas a downlink HARQprocess having two transport blocks is shown as DL HARQ process 120. Inthe first case, DL HARQ process 110 may receive a maximum of onetransport block 112 whereas DL HARQ process 120 may receive a maximum oftwo transport blocks, namely transport block 122 and transport block124. As will be appreciated by those skilled in the art, there may bevarious numbers of these HARQ processes such as 8 HARQ processes in FDD.In this case, buffers for each of these 8 DL HARQ processes would beprovided although a single total area of memory would generally be usedin an actual implementation and divided into 8 or 16 memory portions.

HARQ Buffer Flush

Current technical specifications do not describe HARQ processreconfiguration on transmission mode changes. Various concerns ontransmission mode changes include, but are not limited to, thepartitioning or consolidating of buffers when the number of transportblocks per downlink HARQ process changes as a result of a transmissionmode change. Also, the activation time of the new transmission mode isnot clearly provided for under the current specifications.

A first embodiment of the present disclosure provides for the flushingof all downlink HARQ buffers at the UE whenever the transmission mode ischanged. Any further transmissions or retransmissions to a downlink HARQprocess following the transmission mode change would then be consideredto be the very first transmission to the downlink HARQ process. In otherwords, the new data indicator (NDI) flag for the first transport blockreceived after the transmission mode change for each individualtransport block buffer instantiation would be considered to have beentoggled even if the received transport block corresponds to an HARQretransmission.

A specification change to 3GPP TS 36.331, and in particular to Section5.3.10.6 may be made to reflect the flushing of the buffers, and anexample of such a change may be (new text is shown in boldface):

5.3.10.6 Physical Channel Reconfiguration

The UE shall:

-   -   1> reconfigure the physical channel configuration in accordance        with the received physicalConfigDedicated;    -   1> if the antennaInfo is included and set to ‘explicit Value’:        -   2> if the configured transmissionMode is not ‘tm3’ or ‘tm4’            release ri-ConfigIndex in cqi-ReportPeriodic, if previously            configured;    -   1> else if the antennaInfo is included and set to        ‘defaultValue’:        -   2> release ri-ConfigIndex in cqi-ReportPeriodic, if            previously configured;    -   1> if the transmission mode changes as a result of applying the        received physicalConfigDedicated:        -   2> instruct the MAC to flush all DL HARQ buffers and            consider the next transmission of a transport block for each            DL HARQ process as the very first transmission for that DL            HARQ process;

As will be seen when comparing the example above with the current5.3.10.6 physical channel reconfiguration specifications, a newcondition is added. Specifically, if the transmission mode changes as aresult of applying the received PhysicalConfigDedicated, then the MAC(Medium Access Control) is instructed to flush all downlink HARQ buffersand consider the next transmission of a transport block for eachdownlink HARQ process as the very first transmission for that downlinkHARQ process.

Reference is now made to FIG. 2. In FIG. 2, the procedure starts atblock 210 and proceeds to block 212 in which a check is made todetermine whether the transmission mode has changed. As will beappreciated, the transmission mode change is as a result of receiving aPhysicalConfigDedicated message from the eNB.

From block 212, if the transmission mode has not changed, the procedureproceeds back to block 212 and continues to wait until a transmissionmode change occurs.

From block 212, once the transmission mode change has occurred, theprocedure proceeds to block 214 in which all downlink HARQ buffers areflushed. The procedure then proceeds back to block 212 and continues towait for further transmission mode changes.

HARQ Buffer Flush Only when Number of Transport Blocks Changes

In an alternative embodiment, the flushing of the downlink HARQ buffersat the UE need only occur when the transmission mode changes such thatthe maximum number of transport blocks per downlink HARQ process changesas a result of the transmission mode reconfiguration. As will beappreciated by those in the art, this occurs in the following twosituations in current LTE Release 8 specifications:

-   -   1. the transmission mode changes from one of transmission modes        1, 2, 5, 6 or 7 to one of transmission modes 3 or 4. In this        case, the number of transport blocks per downlink HARQ process        changes from one transport block to two transport blocks; and    -   2. the transmission mode changes from one of transmission modes        3 or 4 to one of transmission modes 1, 2, 5, 6 or 7. In this        case, the number of transport blocks per downlink HARQ process        changes from two to one.

In the alternative embodiment, the UE needs to know its old transmissionmode and its new transmission mode in order to check whether thetransition is one of the two enumerated transmission mode changes above.The UE would already have this required information available.

If a transmission mode change occurs in which the number of transportblocks per downlink HARQ process changes (from one to two or from two toone), the downlink HARQ buffers are flushed and the initial delivery ofany further transport blocks to a downlink HARQ process would beconsidered as the very first transmission for that downlink HARQprocess.

For transmission mode changes where the number of transport blocks perdownlink HARQ process remains the same, there is no need to flush thedownlink HARQ buffers since the HARQ retransmissions could continue in atransparent manner to the UE following the transmission modereconfiguration.

The incremental complexity over the solution where buffers are flushedat each transmission mode change is only minor for the alternativeembodiment and a less visible impact on downlink data throughput may bepresent since potentially useful data for HARQ combining would only bediscarded for a subset of the total possible transmission modereconfiguration scenarios.

The specification for 3GPP TS 36.3.3.1, Section 5.3.10.6 may be changed,for example, as follows (new text is shown in boldface):

5.3.10.6 Physical Channel Reconfiguration

The UE shall:

-   -   1> reconfigure the physical channel configuration in accordance        with the received physicalConfigDedicated;    -   1> if the antennaInfo is included and set to ‘explicit Value’:        -   2> if the configured transmissionMode is not ‘tm3’ or ‘tm4’            release ri-ConfigIndex in cqi-ReportPeriodic, if previously            configured;    -   1> else if the antennaInfo is included and set to        ‘defaultValue’:        -   2> release ri-ConfigIndex in cqi-ReportPeriodic, if            previously configured;    -   1> if the transmission mode changes from one of {‘tm1’, ‘tm2’,        ‘tm5’, ‘tm6’, ‘tm7’} to one of {‘tm3’, ‘tm4’} or from one of        {‘tm3’, ‘tm4’} to one of {‘tm1’, ‘tm2’, ‘tm5’, ‘tm6’, ‘tm7’} as        a result of applying the received physicalConfigDedicated:        -   2> instruct the MAC to flush all DL HARQ buffers and            consider the next transmission of a transport block for each            DL HARQ process as the very first transmission for that DL            HARQ process;

As can be seen from the above, the specification is amended to indicateif the transmission mode changes from one of transmission modes 1, 2, 5,6 or 7 to one of 3 or 4, or if the transmission mode changes from one of3 or 4 to one of transmission modes 1, 2, 5, 6 or 7, then as a resultthe MAC is instructed to flush all downlink HARQ buffers and considerthe next transmission of a transport block for each downlink HARQprocess as the very first transmission for that downlink HARQ process.

Reference is now made to FIG. 3. The procedure of FIG. 3 starts at block310 and proceeds to block 312 in which a check is made to determinewhether a transmission mode change has occurred. If not, the procedureproceeds back to block 312 and continues to wait for a transmission modechange to occur.

From block 312, if a transmission mode change is detected the procedureproceeds to block 314 in which a check is made to determine whether themaximum number of transport blocks per downlink HARQ process changes asa result of the transmission mode change. In other words, the check atblock 314 checks whether the transmission mode change was from one oftransmission modes 1, 2, 5, 6 or 7 to one of transmission modes 3 or 4,or whether the transmission mode change was from one of transmissionmodes 3 or 4 to one of transmission modes 1, 2, 5, 6 or 7. If not, theprocedure proceeds back to block 312, where the procedure continues towait for a transmission mode change.

Conversely, from block 314, if a change is detected where the maximumnumber of transport blocks changes, the procedure proceeds to block 316in which all downlink HARQ buffers are flushed. The procedure thenproceeds back to block 312 in which the procedure continues to wait fora further transmission mode change.

As will be appreciated by those skilled in the art, the checks at block312 and 314 could be combined into a single check in someimplementations. As will also be appreciated by those skilled in theart, an extension of FIG. 3 can be applied in situations where more thantwo transport blocks can be transmitted in one subframe (e.g. in LTE-A).

In a further alternative embodiment, the downlink HARQ buffers for theUE may be flushed only when the maximum number of transport blocks perdownlink HARQ process changes from one transport block per process totwo. In other words, if the transmission mode changes from one oftransmission mode 1, 2, 5, 6 or 7 to one of transmission mode 3 or 4,the downlink HARQ buffers are flushed. In the opposite direction, whenthe transmission mode reconfiguration switches from two transport blocksper downlink HARQ process to one, the soft buffers of the UE would notbe flushed, but only the first of the two transport blocks would beretained. The buffered soft bit values belonging to the second transportblock would be discarded.

Reference is now made to FIG. 4. The procedure of FIG. 4 starts at block410 and proceeds to block 412 in which a check is made to determinewhether a transmission mode change has occurred. If not, the procedureproceeds to loop back to block 412 in which the procedure continues towait for a transmission mode change.

From block 412, once a transmission mode change has been detected theprocedure proceeds to block 414 in which a check is made to determinewhether the transmission mode change is from one of transmission modes1, 2, 5, 6 or 7 to one of transmission modes 3 or 4, or in other wordsfrom a transmission mode having a maximum of one transport block perdownlink HARQ process to a transmission mode with a maximum of twotransmission blocks. If yes, the procedure proceeds to block 416 inwhich all downlink HARQ buffers are flushed. The procedure then proceedsback to block 412 to wait for a further transmission mode change.

From block 414, if the change was not from a transmission mode havingone transport block per downlink HARQ process to a transmission modehaving two transmission blocks, the procedure proceeds to block 420 inwhich a check is made to determine whether the transmission mode changewas from one of transmission modes 3 or 4 to one of transmission modes1, 2, 5, 6 or 7. Thus, the check of block 420 determines whether thetransmission mode change is from a transmission mode having twotransport blocks per downlink HARQ process to a transmission mode havingone transmission block. If yes, the procedure proceeds to block 422 inwhich the buffer for the second transport block of each downlink HARQprocess is discarded. The procedure then proceeds back to block 412 inwhich a change in transmission mode is checked for.

From block 420, if the change was not from one of transmission modes 3or 4 to one of transmission modes 1, 2, 5, 6 or 7, then the procedureproceeds back to block 412. As will be appreciated, since thetransmission mode change was not from one in which there is a singletransport block to one where there are two transport blocks, nor was thechange from a transmission mode in which there are two transport blocksto one in which there is only one transport block, the number oftransport blocks remains the same between the two transmission modes andtherefore no buffer flush is required.

As will be appreciated by those in the art, the checks of blocks 414 and420 could also be performed independently of each other and in separateprocedures. Furthermore, in some embodiments the check of either block414 or block 420 may be unnecessary.

Reference is made to FIG. 4A. In FIG. 4A, the procedure of FIG. 4 hasbeen modified by removing the check at block 420. In particular, theprocedure of FIG. 4A starts at block 410 and proceeds to block 412 inwhich a check is made to determine whether a transmission mode changehas occurred. If no, the procedure continues to check for a transmissionmode change at block 412.

If a transmission mode change is detected at block 412 the procedureproceeds to block 414 in which a check is made to determine whether thetransmission mode change was from a transmission mode having onetransport block to a transmission mode having two transport blocks. Ifyes, the procedure proceeds to block 416 and flushes all of the downlinkHARQ buffers. If, in block 414 the check is negative, the procedureproceeds back to block 412. Further from block 416 the procedureproceeds back to block 412.

Reference is now made to FIG. 4B. The procedure of FIG. 4B is similar tothat of FIG. 4 with the exception that the check of block 414 has beenremoved. In particular, the procedure of FIG. 4B starts at block 410 andproceeds to block 412 in which a check is made to determine whether atransmission mode change has occurred. If no, the procedure continues tocheck for a transmission mode change at block 412.

Once a transmission mode change is detected at block 412 the procedureproceeds to block 420 in which a check is made to determine whether thechange was from a transmission mode having two transport blocks to atransmission mode having one transport block. If yes, the procedureproceeds to block 422 in which the buffer for the second transport blockis discarded. From block 422 the procedure proceeds to block 412 tocheck for further transmission mode changes.

From block 420, if the change is not from a transmission mode having twotransport blocks to a transmission mode having one transport block, theprocedure proceeds to block 412 to continue checking for furthertransmission mode changes.

In an additional alternative embodiment, if the first of the twotransport blocks had been successfully decoded in the most recentdecoding attempt on that transport block and there were thus no bufferedsoft bit values for the first transport block that had not beensuccessfully decoded, then the soft bit values belonging to the firsttransport block could be discarded and the soft bit values (and otherrelevant parameters) belonging to the second transport block (assumingthat the second transport block had not been successfully decoded in themost recent decoding attempt on that transport block) could be handledas the “first” transport block (which would be retained).

Reference is now made to FIG. 5. In the further alternative embodimentthe procedure starts at block 510 and proceeds to block 512 in which acheck is made to determine whether a transmission mode has changed. Ifno, the procedure proceeds to loop back to block 512 and wait until atransmission mode change has occurred.

From block 512, once a transmission mode change has occurred, theprocedure proceeds to block 514 to determine whether the change was froma transmission mode having a maximum of one transport block to atransmission mode having a maximum of two transport blocks. If yes, theprocedure proceeds to block 516 in which all downlink HARQ buffers areflushed. From block 516 the procedure proceeds back to block 512 andwaits for further transmission mode change.

If, in block 514, it is determined that the change was not from atransmission mode with one transport block to a transmission mode withtwo transport blocks, the procedure proceeds to block 520. In block 520a check is made to determine whether the change was from a transmissionmode having two transport blocks to a transmission mode having onetransport block. If no, the procedure proceeds back to block 512 andcontinues to wait for a further transmission mode change.

From block 520, if it is determined that the change was from atransmission mode having two transport blocks to a transmission modehaving one transport block the procedure proceeds to block 530 in whicha check is made to determine whether all of the soft bits for the firsttransport block have been successfully decoded. If no, the processproceeds to block 532 in which the buffer for the second transport blockis discarded. The procedure then proceeds from block 532 to block 512 inwhich a further transmission mode change is awaited.

From block 530, if all of the soft bits for the first transport blockare successfully decoded, the procedure proceeds to block 534 in whichthe contents of the first transport block are discarded and the secondtransport block contents are retained.

As will be appreciated by those skilled in the art, the checks at blocks514 and 520 could be performed in independent procedures and in somecases one of the checks could be excluded completely. If the procedureof FIG. 5 excludes the check of block 520 then the procedure would bemodified to the procedure of FIG. 4A above.

Reference is now made to FIG. 5A. FIG. 5A shows the procedure of FIG. 5in which the check of block 514 has been removed. In particular, theprocedure of FIG. 5A starts at block 510 and proceeds to block 512 inwhich a check is made to determine whether a transmission mode changehas occurred. If no, the procedure continues to check for a transmissionmode change at block 512.

Once a transmission mode change has been detected at block 512 theprocedure proceeds to block 520 in which a check is made to determinewhether the change is from a transmission mode having two transportblocks to a transmission block having one transport block. If no, theprocedure proceeds to block 512 to check for further transmission modechanges.

From block 520, if the change in transmission modes is from atransmission mode having two transport blocks to a transmission modehaving one transport block the procedure proceeds to block 530 in whicha check is made to determine whether all soft bits for the firsttransport block have been successfully decoded. If the check of block530 determines that all soft bits for the first transport block havebeen successfully decoded, the procedure proceeds to block 534 in whichthe buffer for the first transport block is discarded and the contentsof the second transport block are treated as the first transport block.

From block 530 if the check determines that not all soft bits for afirst transport block have been successfully decoded, the procedureproceeds to block 532 in which the buffer for the second transport blockis discarded.

From blocks 532 and 534 the procedure proceeds to block 512 to continuechecking for further transmission mode changes.

As will be appreciated by those in the art, in situations where thereare more than two transport blocks possible, the procedures of FIGS. 4,4A, 4B, 5 and 5A could be modified to discard the buffers of the secondand subsequent transport blocks and keep the first transport block, orif the soft bits in the first transport block have all been successfullydecoded, the soft bits of a second or subsequent transport block couldbe transferred to the first transport block, and the subsequenttransport block bits could be discarded. Additionally, the procedures ofFIGS. 4, 4A, 4B, 5 and 5A could be modified to handle the more generalsituation of a transmission mode change from M transport blocks per HARQprocess to N transport blocks per HARQ process (or vice versa), whereM>1, N>1, and M>N. In this situation, M-N transport blocks would bediscarded, and N transport blocks would be retained.

Downlink HARQ Buffer Repartitioning

In a further embodiment, instead of flushing a buffer, repartitioningcould occur to maintain the content or partial content of a buffer. Inparticular, when a transmission mode change occurs that results in achange in the number of transport blocks per downlink HARQ process, theUE could still maintain the existing contents of its soft combiningbuffers to allow for potential downlink HARQ retransmissions followingthe change of the transmission mode.

In particular, reference is now made to FIG. 6. FIG. 6 shows a downlinkHARQ process 610 and a downlink HARQ process 620. The transition from afirst transmission mode with two transport blocks, as illustrated bydownlink HARQ process 610, to a downlink HARQ process 620 having onlyone transmission block could occur similar to the transition asdescribed above with regard to FIG. 4. In particular, as seen indownlink HARQ process 610, two buffers, one for each transport blockexist. These are labeled as buffer 612 and buffer 614.

Furthermore, buffer 612 includes an allocated portion 616 and a usedportion 617 whereas buffer 614 includes an allocated portion 618 and aused portion 619. In the example of FIG. 6, the used portion takes uponly a portion of the allocated portion of the downlink HARQ process foreach buffer for each transport block. The size of the allocated portionmay be fixed (for example, according to Equation 1) but the size of theused portion depends on the actual size of the coded transport block(including both systematic (information) and parity bits), which mayvary from one transport block to another.

During a transmission mode transition as shown in FIG. 6, any bufferedsoft bits associated with the second transport block would be discarded,and any buffered soft bits associated with the first transport blockwould be retained. The stored NDI flag associated with the firsttransport block would also be retained in order to determine whether anyfuture transport block transmissions that are received for this downlink(DL) HARQ process are new transmissions (NDI flag is toggled) orretransmissions of the currently buffered transport block (NDI flag isnot toggled). The used portion 617 of the first transport block buffer612 is thus retained as part of the newly expanded allocated buffer 622of DL HARQ process 620.

FIG. 6 could further be extended to situations with more than twotransport blocks. In this case, the used portion 617 of the firsttransport block buffer 612 could be retained and the soft bitsassociated with the second transport block and subsequent transportblocks could be discarded. In addition, where the transmission modechange is from a mode with multiple (M) transport blocks to another modewith multiple (N) transport blocks, where M>N, then the used portions ofthe first N transport blocks would be retained, while the subsequent M−Ntransport blocks would be discarded.

Reference is now made to FIG. 7. FIG. 7 shows a transition of a downlinkHARQ process 710 having a transmission mode with one transport blockbuffer to downlink HARQ process 720 having a transmission mode with twobuffers 722 and 724.

Downlink HARQ process 710 includes a single buffer with an allocatedportion 714 and a used portion 712.

On transition, the allocated area 714 is reduced for the downlink HARQprocess 720 with two transport blocks. Any buffered soft bits associatedwith the first transport block, namely used portion 712, are retained,and any values corresponding to the second transport block areinitialized. In the case of more than two transport blocks, subsequenttransport blocks would also be initialized. This includes the stored NDIflag for the second or subsequent transport blocks. Essentially, when asecond transport block is first received following a transmission modechange, it would be considered to be the very first transmission forthat half of the downlink HARQ process (i.e. the NDI flag would beconsidered to have been toggled). Conversely, a future reception of atransmission corresponding to the first transport block would bedetermined to be a new transmission or a retransmission depending(respectively) upon whether the received NDI flag was toggled or not ascompared to the stored NDI flag value.

A change in the 3GPP TS 36.331 specification to reflect the retention ofdata on transition may be as follows (new text is shown in boldface):

5.3.10.6 Physical Channel Reconfiguration

The UE shall:

-   -   1> reconfigure the physical channel configuration in accordance        with the received physicalConfigDedicated;    -   1> if the antennaInfo is included and set to ‘explicit Value’:        -   2> if the configured transmissionMode is not ‘tm3’ or ‘tm4’            release ri-ConfigIndex in cqi-ReportPeriodic, if previously            configured;    -   1> else if the antennaInfo is included and set to        ‘defaultValue’:        -   2> release ri-ConfigIndex in cqi-ReportPeriodic, if            previously configured;    -   1> if the transmission mode changes from one of {‘tm1’, ‘tm7’}        to one of {‘tm3’, ‘tm4’} as a result of applying the received        physicalConfigDedicated:        -   2> instruct the MAC to consider the next transmission of a            second transport block for each DL HARQ process as the very            first transmission for that transport block of DL HARQ            process;    -   1> if the transmission mode changes from one of {‘tm3’, ‘tm4’}        to one of {‘tm1’, ‘tm2’, ‘tm5’, ‘tm6’, ‘tm7’} as a result of        applying the received physicalConfigDedicated:        -   2> instruct the MAC to discard any buffered soft bits and            corresponding parameters (e.g. NDI flag, transport block            size) associated with the second transport block of each DL            HARQ process;

As can be seen from the above, transitioning from a transmission modewith one transport block per downlink HARQ process to a transmissionmode with two transport blocks results in the MAC considering the nexttransmission of the second transport block to be an initialtransmission. Also, transitioning from a transmission mode with twotransport blocks to a transmission mode with one transport block resultsin the MAC discarding buffered soft bits for the second transport block.

Reference is now made to FIG. 8. FIG. 8 shows the procedure as redefinedin the 3GPP TS 36.331 modifications above. In particular the procedurestarts at block 810 and proceeds to block 812 in which a check is madeto determine whether a transmission mode change has occurred. If not,the procedure proceeds back to block 812 and continues to check for atransmission mode change.

Conversely, if a transmission mode change is detected in block 812, theprocedure proceeds to block 814 in which a check is made to determinewhether the transmission mode changes from a mode in which there is onetransport block per downlink HARQ process to a mode in which there aretwo transport blocks. If the mode changes from a mode with one transportblock to a mode with two transport blocks, the procedure proceeds toblock 820. In block 820 the buffer is kept for the first transport blockand the MAC is instructed to consider the next transmission of a secondtransport block for each downlink HARQ process to be the very firsttransmission for that transport block.

From block 820 the procedure proceeds back to block 812 and continues tocheck for a transmission mode change.

If, in the check of block 814, it is determined that the transmissionmode change was not from a mode with one transport block to a mode withtwo transport blocks, the procedure proceeds to block 830. In block 830,a check is made to determine whether the change in the transmission modewas from a mode that has two transport blocks per downlink HARQ processto a mode with one transport block. If yes, the procedure proceeds toblock 832 and discards the buffered soft bits for the second transportblock.

From block 832, the procedure proceeds back to block 812 and continuesto check for a transmission mode change.

From block 830, if the transmission mode change was not from a mode withtwo transport blocks to a mode with one transport block then, whencombining the checks in block 814 and block 830, the transmission modechange must have been from a mode in which there was one transport blockto another mode with which there was one transport block, or atransmission mode in which there were two transport blocks to anothertransmission mode in which there were two transport blocks. In thiscase, the procedure proceeds back to block 812 and continues to checkfor a further transmission mode change since no buffers need to beflushed and no bits need to be discarded.

As will be appreciated by those skilled in the art, the checks of blocks814 and 830 could be performed in separate procedures and in some casesthe check of either of blocks 814 or 830 could be excluded.

Reference is now made to FIG. 8A. In the procedure of FIG. 8A, the checkof block 830 has been eliminated. Specifically, the procedure of FIG. 8Astarts at block 810 and proceeds to block 812 in which a check is madeto determine whether a transmission mode change has occurred. If no, theprocedure continues to check for a transmission mode change at block812.

Once a transmission mode change has been detected at block 812, theprocedure proceeds to block 814 in which a check is made to determinewhether the transmission mode change was from a transmission mode havingone transport block to a transmission mode having two transport blocks.If yes, the procedure proceeds to block 820 in which the buffer for thefirst transport block is kept and the next transmission on the secondtransport block is considered to be the first transmission on thattransmission block. From block 820, the procedure proceeds back to block812 to continue checking for further transmission mode changes.

From block 814, if the change was not from a transmission mode havingone transport block to a transmission mode having two transport blocks,the procedure proceeds back to block 812 to continue checking forfurther transmission mode changes.

Conversely, if block 814 is eliminated from the procedure of FIG. 8, theprocedure would then be the same as that of FIG. 4B described above.

UE Implemented Solution

As will be appreciated by those skilled in the art, any of the above maybe implemented by making the changes to the 3GPP TS 36.331specifications. Alternatively, since a complete failure of operations atthe mobile device is not expected based on the transmission mode change,a further alternative embodiment would be to leave the choice of whichsolution to implement up to a UE manufacturer. In other words, the UEmanufacturer could choose to implement the procedure of FIG. 2, 3, 4,4A, 4B, 5, 5A, 8 or 8A. As will be appreciated by those in the art, suchan implementation would require no changes in any Release 8 LTEspecifications.

eNB Scheduling During a Transmission Mode Change

A further item that is unclear with current specifications is the exacttiming of the transmission mode change at a UE. Specifically, theactivation time of a downlink transmission mode reconfiguration cannotbe specified in E-UTRA.

The E-UTRA RRC does not support the specification of an exact activationtime in reconfiguration procedures. If a new mode of downlinktransmission is applied by the eNB earlier than the time when the UEcompletes reconfiguration, reception of the data by the UE may fail.Similarly, if the old downlink transmission mode continues to be appliedby the eNB after the time when the UE completes reconfiguration,reception of the data by the UE may also fail.

As will be appreciated, when transmission of one or two transport blocksto a downlink HARQ process occurs before the transmission mode change,and an HARQ transmission to the same downlink process occurs after thetransmission mode change, if the number of transport blocks per downlinkHARQ process has changed there may be a problem with the receipt of thetransport block data.

If the downlink transmission mode is reconfigured and the maximum numberof transport blocks that can be received in the subframe remains thesame, then a retransmission to a downlink HARQ process can be handledfollowing the transmission mode change, since there are no modificationsto the downlink HARQ buffer size or to the number of NDI flagsassociated with each downlink HARQ process. However, if the transmissionmode reconfiguration results in a change in the maximum number oftransport blocks that can be received within a subframe, then thehandling of a retransmission to a downlink HARQ process is potentiallyambiguous according to the current E-UTRA specifications. For example,if the transmission mode changes from one of transmission mode 1, 2, 5,6 or 7 to one of transmission mode 3 or 4, then combining of a newretransmission with the previous buffered soft bits may not occurcorrectly unless the reconfiguration of and transmission to the downlinkHARQ buffer memory is handled properly. As a result reception ofretransmitted data may fail and degrade the overall data transmissionrate.

Reference is made to Table 3 below. Table 3 shows downlink controlinformation (DCI) formats that are addressed to the C-RNTI (Cell RadioNetwork Temporary Identifier) of a UE that the UE is expected to be ableto receive on the physical downlink control channel (PDCCH) while ineach transmission mode.

TABLE 3 Downlink-related DCI formats (addressed to the UE's C-RNTI) tobe received for each configured downlink transmission mode TransmissionDL DCI Mode Formats 1 1A 1 2 1A 1 3 1A 2A 4 1A 2 5 1A 1D 6 1A 1B 7 1A 1

As seen in Table 3 above, each transmission mode has various downlinkDCI formats. In particular, the number underneath the format indicatesthe maximum number of transport blocks per transmission opportunitywhile a letter may be used to specify decoding procedures includingmodulation, code rate, physical resources, NDI flag, HARQ process numberamong other factors.

As can be seen from Table 3, the UE may expect to receive a DCI format1A and one other downlink DCI format while in each transmission mode.The latter downlink DCI format varies from one transmission mode toanother but DCI format 1A is common to all transmission modes.

Consequently, in one embodiment of the present disclosure an eNB may berequired to use DCI format 1A for downlink transmission to a UE in theimmediate time periods surrounding a transmission mode change at the UE,since the exact timing of the transmission mode change is unknown to theeNB, but the eNB does know that the UE will be able to receive DCIformat 1A in both the old and new transmission modes.

Reference is now made to FIG. 9. FIG. 9 provides an example in which atransition is made from, for example, transmission mode 4 in which DCI 2would normally be used, to transmission mode 2 in which DCI 1 wouldnormally be used.

Prior to ordering a transmission mode change, the eNB can use DCI 2 totransmit to the UE. However, uncertainty surrounding the actualtransmission mode change to the UE is reflected in a time window whenthe eNB is not sure of which of the two transmission modes the UE willbe configured in. Consequently, the eNB can use DCI 1A during thisuncertainty window and still be sure that the UE will be able to receivethe corresponding transmissions. Following the transmission mode changewindow, the eNB can then use DCI 1 which is part of transmission mode 2to transmit to the UE.

Referring to FIG. 9, the time period prior to transmission mode changeis labeled using reference numeral 910. The time period after thetransmission mode change is labeled as reference numeral 920. Theuncertainty window for the transmission mode change is labeled withreference numeral 930.

In the example of FIG. 9, the UE may be in transmission mode 4 withinthe region labeled with reference numeral 910. In this region, as seenfrom Table 3 above, the DCI utilized is normally DCI 2.

The UE may be in transmission mode 1 in the region labeled withreference numeral 920. In this region, as seen from Table 3 above, theDCI normally used is DCI 1.

In the uncertainty window 930 the eNB may transmit using DCI 1A,ensuring that the UE is able to decode the data that is provided duringthe uncertainty period.

Further, since the eNB knows, within period 910, that a transition to anew transmission mode is occurring, the eNB can further start to disabletransport block 2 in the area of 910 as the subframes in the area of 910approach the uncertainty window of 930. This will ensure that there areno or few active soft bits in any transport block buffer associated withtransport block number 2.

As will be appreciated by those in the art, the example of FIG. 9 ismerely meant to be illustrative and is not limiting. In particular, thenumber of subframes shown in each of the transition areas includinguncertainty area 930 is not meant to be fixed to the number of subframesillustrated. Rather, the number of subframes illustrated is merely anexample, and the actual window lengths may differ from those shown.

Further, if more than two transport blocks exists, the eNB could startto disable transmission on the second and any subsequent transportblocks prior to the uncertainty window. In the more general case, if thedownlink transmission mode change is from a transmission mode with Mtransport blocks per transmission opportunity to a differenttransmission mode with N transport blocks, where M≠N, then the eNB couldensure that only min(M,N) transport blocks are transmitted to the UE pertransmission opportunity in the time period leading up to thetransmission mode change uncertainty window.

In an alternative embodiment, the eNB can make no downlink transmissionsand/or retransmissions during the transmission mode uncertainty window.In some situations, however, sending no transmissions might be difficultduring periods of heavy downlink traffic without a noticeabledegradation of data transmission rates.

The specification for 3GPP TS 36.331 may be changed to accommodate thetransmission mode DCI utilization described above. In particular, thespecification may be changed to read (new text is shown in boldface):

5.3.10.6 Physical Channel Reconfiguration

The UE shall:

-   -   1> reconfigure the physical channel configuration in accordance        with the received physicalConfigDedicated;    -   1> if the antennaInfo is included and set to ‘explicit Value’:        -   2> if the configured transmissionMode is not ‘tm3’ or ‘tm4’            release ri-ConfigIndex in cqi-ReportPeriodic, if previously            configured;    -   1> else if the antennaInfo is included and set to        ‘defaultValue’:        -   2> release ri-ConfigIndex in cqi-ReportPeriodic, if            previously configured;    -   Note: Prior to and during antenna mode reconfiguration the eNB        shall transmit only one transport block in a subframe or the eNB        shall not make any transmission on DRBs.

As seen above, the specification change includes a note that prior toand during the antenna mode reconfiguration the eNB shall transmit amaximum of only one transport block in a subframe or the eNB shall notmake any transmission on data radio bearers.

The embodiment is further illustrated with regard to FIG. 10. FIG. 10shows a flow diagram of a procedure at the eNB for communication duringa transmission mode change.

In particular, in the example of FIG. 10 the procedure starts at block1010 and proceeds to block 1012 in which a check is made to determinewhether a transmission mode changes from one where there are twotransport blocks per downlink HARQ process to one where there is onetransport block is approaching. If yes, the procedure proceeds to block1014 and data transmission is limited to the first transmission blockfor each downlink HARQ process. The procedure then proceeds to 1016.

If there is no transmission mode change in which there are two transportblocks currently and one transport block after the change, then theprocedure proceeds from block 1012 to 1016 as well.

As will be appreciated by those skilled in the art, blocks 1012 and 1014are optional and do not necessarily need to be implemented.

In block 1016, a check is made to determine whether the transmissionmode change is within the uncertainty window, as shown in FIG. 9. If, inblock 1016 it is determined that the UE is in the transmission modeuncertainty window the procedure proceeds to block 1020 and the eNB useseither DCI 1A for data transmissions or else blocks data transmissionsto the UE. The procedure then proceeds to block 1022 and ends.

From block 016, if the procedure is not in the transmission modeuncertainty window, the procedure proceeds to block 1030 in which theDCI format that is normally used for the transmission mode in which theUE is currently in (i.e. the DCI format (other than DCI 1A) from Table 3for a particular transmission mode). The procedure then proceeds toblock 1022 and ends.

Transport Block Sizing During a Transmission Mode Change Window

Having regard to FIGS. 6 and 7 above, these figures provide for themaintaining of existing soft buffer contents of a UE in a downlink HARQprocess following a transmission mode change. However, one potentialproblem with the solution of FIGS. 6 and 7 is when the utilized portionexceeds the allocated buffer size when a buffer is divided in two ormore. This may happen, for example, when moving from a single transportblock transmission mode to a dual transport block transmission mode.

When two transport blocks are associated with each downlink HARQ processand one of the transport blocks is too large to fit within the availablesoft buffer memory for that transport block, some of the parity bits arenot considered for transmission of that transport block. In other words,the eNB will automatically remove some of the parity bits during therate matching procedure, as described in section 5.1.4.1.2 of 3GPP TS36.212. These parity bits will never be transmitted.

The UE knows that these parity bits will never be transmitted andperforms its forward error correction (FEC) decoding appropriately.

Reference is now made to FIG. 11. FIG. 11 shows a soft buffer memoryusage for two transport blocks. As seen with reference numeral 1110, theavailable soft buffer memory for a transport block is of a specificsize.

In a first transport block 1120 the systematic bits and parity bits allfit within the memory size 1110. Conversely, in a second transport block1130, the systematic bits and parity bits do not fit into the softbuffer memory 1110. The excess parity bits, as shown with referencenumeral 1132 are thus never transmitted for transport block B.

Where an issue may exist is when the transmission mode change alters thenumber of transport blocks associated with each downlink HARQ process,as shown above with regard to FIGS. 6 and 7. If a transport block thatis being retained for possible HARQ retransmission following thetransmission mode change is too large, then the corresponding softbuffer contents for that transport block may become ambiguous. The eNBdoes not know the exact point in time at which the transmission modewill be changed by the UE, as seen above with regard to FIG. 9.Consequently, a situation may arise where the eNB wishes to perform aretransmission of a large transport block but does not know whether ornot to include the extra parity bits that would otherwise be truncatedfor the case of two transport blocks per downlink HARQ process.

Reference is now made to FIG. 12. FIG. 12 shows a transmission modechange from two transport blocks 1212 and 1218 per downlink HARQprocess, to a single transport block 1224. In this case, the soft buffercontents 1214 for the first transport block 1210 may require expandingfor the single transport block soft buffer contents 1222. Forsimplicity, only the first transport block is shown when two transportblocks are associated with each downlink HARQ process.

Thus, in FIG. 12, the transmission mode change occurs with a change fromtwo transport blocks to one transport block per downlink HARQ process.However, the buffered transport block is sufficiently large that some ofits parity bits were originally truncated in order to fit within theavailable soft buffer memory. When only one transport block isassociated with each downlink HARQ process, these truncated parity bitswould then be transmitted by the eNB, so the UE would insert zeros ornull values into the appropriate bit locations (corresponding to thetruncated or punctured parity bit positions) while expanding thebuffered transport block, as shown by reference numeral 1222.

Referring to FIG. 13, a similar but reverse procedure occurs when atransmission mode changes from one transport block to two transportblocks per downlink HARQ process. If the buffered transport block is toolarge, it may be necessary to compact the buffered transport block byremoving or puncturing some of the soft bit values since thecorresponding parity bits would never be transmitted in the twotransport blocks per downlink HARQ process scenario. An issue ariseswhen the UE may have performed the expansion or contraction of thebuffer soft bit values when the transmission mode changeover is applied,but the eNB does not know exactly when the action was performed, so theeNB does not know whether or not to transmit any extra parity bits thatwould normally be discarded for the case of two transport blocks perdownlink HARQ process.

Referring to FIG. 13, a single transport block downlink HARQ process isshown at reference numeral 1310 with soft buffer memory 1312 and abuffered transport block 1314. A dual transport block downlink HARQprocess is shown at reference numeral 1320 with transport block softbuffers 1322 and 1328. As seen in the downlink HARQ process 1320, theextra parity bits from soft bit values 1314 are truncated or puncturedfor the first transport block's soft bit values 1324.

A number of solutions to the above issues may exist. In a firstsolution, the downlink HARQ buffer at the UE may be flushed when atransmission mode change occurs that results in a change in the numberof transport blocks per downlink HARQ process, as described above withregard to FIG. 2. The eNB then avoids any downlink transmissions to theUE during the transmission change uncertainty window.

In an alternative embodiment, the eNB ensures that any transport blocksthat are transmitted or retransmitted during the transmission modechange uncertainty window have a sufficiently small size so that thereis no need to truncate or puncture any of the parity bits when twotransport blocks per downlink HARQ process are used. If any excessivelylarge transport blocks are buffered at the UE when a transmission modechange order is issued by the eNB, then the eNB may have to manuallyflush those transport blocks from the UE's downlink HARQ soft buffers bytoggling the NDI flag for the associated transport blocks.

A further solution to the issue above is that the UE may be able topuncture some of the received soft bits from the large transport blockand still perform the soft combining before the turbo decoding. As willbe appreciated, the issue with the truncating of parity bits occurs whenthe eNB transmits a larger transport block than the UE can fit into itssoft bit memory for the case of two transport blocks per downlink HARQprocess. The UE however, has all the relevant transmission resourceparameters such as MCS (Modulation & Coding Scheme), RV (RedundancyVersion) among others. The MCS specifies the modulation level (e.g.QPSK, 16QAM, 64QAM) and code rate that are used for a particulartransmission. The redundancy version specifies which exact set ofsystematic and/or parity bits are being sent in a particulartransmission.

In a further embodiment, a particular downlink HARQ process could beflushed at the UE when a transmission mode change occurs only when allof the following conditions are satisfied:

-   -   1) The transmission mode reconfiguration involves a change in        the number of transport blocks per downlink HARQ downlink        process; and    -   2) The transport block size of at least one transport block        contained in that downlink HARQ process' soft buffer is such        that the number of transmitted parity bits changes as a result        of the soft buffer memory repartitioning.

In the solution above, the buffer will be flushed when the transportblock size that requires truncation is contained within the downlinkHARQ process' buffer.

Furthermore, for the case of switching from one transport block perdownlink HARQ process to two transport blocks, a further solution isthat a particular downlink HARQ process will not repartition the softbuffer memory until the current transport block is completed. That is,soft combining for the current transport block will continue while theeNB sends a DCI 1A or 2 or 2A with a non-toggled NDI flag. In the caseof DCI 2 or 2A being used, the second transport block would need to bedisabled as specified in Section 7.1.7.2 of TS36.213. As soon as thedownlink HARQ process receives a DCI 1A with a toggled NDI, a DCI 2/2Awith one transport block enabled and a toggled NDI, or a DCI 2/2A withboth transport blocks enabled whether or not the NDI flag is toggled ornot, the downlink HARQ process could automatically be flushed and thecorresponding soft combining buffer will be repartitioned. This alsoaddresses the potential problem of the transport block being too largefor buffer repartitioning.

The specification may be changed by adding a note in 3GPP TS 36.331,section 5.3.10.6 as follows (new text is shown in boldface):

5.3.10.6 Physical Channel Reconfiguration

The UE shall:

-   -   1> reconfigure the physical channel configuration in accordance        with the received physicalConfigDedicated;    -   1> if the antennaInfo is included and set to ‘explicit Value’:        -   2> if the configured transmissionMode is not ‘tm3’ or ‘tm4’            release ri-ConfigIndex in cqi-ReportPeriodic, if previously            configured;    -   1> else if the antennaInfo is included and set to        ‘defaultValue’:        -   2> release ri-ConfigIndex in cqi-ReportPeriodic, if            previously configured;    -   Note: Prior to and during antenna mode reconfiguration the eNB        shall transmit only one transport block in a subframe or the eNB        shall not make any transmission on DRBs. The eNB shall also        consider the soft buffer size of a DL HARQ process after the        reconfiguration when selecting a transport block size.

Applicability to LTE Advanced

In LTE Advanced, downlink MIMO may be enhanced to support 8×8 MIMOtransmission. All of the above proposals are also applicable to LTEAdvanced downlink. Moreover, LTE Advanced may also support MIMOtransmissions in the uplink direction and there may consequently bemultiple uplink transmission modes. These uplink transmission modeswould be configured by RRC in a similar matter to the current LTEdownlink transmission mode reconfiguration and therefore the proposalsabove are also applicable with regard to uplink transmissions. In oneembodiment, the previously described proposals for downlink HARQoperation may be modified in order to address any transmission modechangeover timing issues and/or maintaining data transmission rates inthe uplink direction. For example:

-   -   1) The eNB starts new transmissions by providing uplink grants        with new data indications rather than HARQ retransmissions when        the uplink transmission mode is reconfigured;    -   2) The eNB starts new transmissions by providing uplink grants        with new data indications when the uplink transmission mode is        reconfigured and the maximum number of transport blocks per        uplink HARQ process is changed;    -   3) The eNB provides uplink grants only for one transport block        per uplink HARQ process prior to and/or during the uplink        transmission mode reconfiguration; and    -   4) In the more general case, if the uplink transmission mode        change is from a transmission mode with M transport blocks per        transmission opportunity to a different transmission mode with N        transport blocks per transmission opportunity, where M≠N, then        the eNB could ensure that transmission grants covering only        min(M,N) transport blocks per transmission opportunity are        provided to the UE in the time period leading up to the        transmission mode change uncertainty window.

The above proposals are also applicable to E-UTRAN Release 9specifications and may be applicable to other technology areas wheremultiple uplink or downlink transport blocks per transmissionopportunity are provided and a transition between transmission modesexists where one or more transport blocks may be enabled or disabled.

Based on the above, if a transmission mode change is detected by the UE,the UE can manipulate the HARQ soft buffer by flushing the buffer,flushing the buffer only if the maximum number of transport blocks perHARQ process changes, flushing the HARQ buffer if the transmission modechanges from one with one transport block to two transport blocks perHARQ process and discarding the second transport block if the transitionis from a mode with two transport blocks to a mode with one transportblock, keeping a first transport block and initializing a secondtransport block when the transmission mode change is from a mode withone transport block to one with two transport blocks,

The above can be implemented on any user equipment on the receiving sideand any network element such as an evolved Node B on the sending side.On the sending side, the network element will include a communicationssubsystem to send the information concerning transport layers utilized.

For the UE side, FIG. 14 is a block diagram illustrating a UE capable ofbeing used with preferred embodiments of the apparatus and method of thepresent application. Mobile device 1400 is preferably a two-way wirelesscommunication device having at least voice communication capabilities.Depending on the exact functionality provided, the wireless device maybe referred to as a data messaging device, a two-way pager, a wirelesse-mail device, a cellular telephone with data messaging capabilities, awireless Internet appliance, or a data communication device, asexamples.

Where UE 1400 is enabled for two-way communication, it will incorporatea communication subsystem 1411, including both a receiver 1412 and atransmitter 1414, as well as associated components such as one or more,preferably embedded or internal, antenna elements 1416 and 1418, localoscillators (LOs) 1413, and a processing module such as a digital signalprocessor (DSP) 1420. As will be apparent to those skilled in the fieldof communications, the particular design of the communication subsystem1411 will be dependent upon the communication network in which thedevice is intended to operate.

Network access requirements will also vary depending upon the type ofnetwork 1419. An LTE UE may require a subscriber identity module (SIM)card in order to operate on the LTE or LTE-A network. The SIM interface1444 is normally similar to a card-slot into which a SIM card can beinserted and ejected like a diskette or PCMCIA card. The SIM card mayhold key configuration 1451, and other information 1453 such asidentification, and subscriber related information.

When required network registration or activation procedures have beencompleted, UE 1400 may send and receive communication signals over thenetwork 1419. As illustrated in FIG. 14, network 1419 can consist ofmultiple antennas communicating with the UE. These antennas are in turnconnected to an eNB 1470.

Signals received by antenna 1416 through communication network 1419 areinput to receiver 1412, which may perform such common receiver functionsas signal amplification, frequency down conversion, filtering, channelselection and the like, and in the example system shown in FIG. 14,analog to digital (A/D) conversion. A/D conversion of a received signalallows more complex communication functions such as demodulation anddecoding to be performed in the DSP 1420. In a similar manner, signalsto be transmitted are processed, including modulation and encoding forexample, by DSP 1420 and input to transmitter 1414 for digital to analogconversion, frequency up conversion, filtering, amplification andtransmission over the communication network 1419 via antenna 1418. DSP1420 not only processes communication signals, but also provides forreceiver and transmitter control. For example, the gains applied tocommunication signals in receiver 1412 and transmitter 1414 may beadaptively controlled through automatic gain control algorithmsimplemented in DSP 1420.

UE 1400 preferably includes a microprocessor 1438 which controls theoverall operation of the device. Communication functions, including dataand voice communications, are performed through communication subsystem1411. Microprocessor 1438 also interacts with further device subsystemssuch as the display 1422, flash memory 1424, random access memory (RAM)1426, auxiliary input/output (I/O) subsystems 1428, serial port 1430,one or more keyboards or keypads 1432, speaker 1434, microphone 1436,other communication subsystems 1440 such as a short-range communicationssubsystem and any other device subsystems generally designated as 1442.Serial port 1430 could include a USB port or other port known to thosein the art.

Some of the subsystems shown in FIG. 14 perform communication-relatedfunctions, whereas other subsystems may provide “resident” or on-devicefunctions. Notably, some subsystems, such as keyboard 1432 and display1422, for example, may be used for both communication-related functions,such as entering a text message for transmission over a communicationnetwork, and device-resident functions such as a calculator or tasklist.

Operating system software used by the microprocessor 1438 is generallystored in a persistent store such as flash memory 1424, which mayinstead be a read-only memory (ROM) or similar storage element (notshown). Those skilled in the art will appreciate that the operatingsystem, specific device applications, or parts thereof, may betemporarily loaded into a volatile memory such as RAM 1426. Receivedcommunication signals may also be stored in RAM 1426.

As shown, flash memory 1424 can be segregated into different areas forboth computer programs 1458 and program data storage 1450, 1452, 1454and 1456. These different storage types indicate that each program canallocate a portion of flash memory 1424 for their own data storagerequirements. Microprocessor 1438, in addition to its operating systemfunctions, preferably enables execution of software applications on theUE. A predetermined set of applications that control basic operations,including at least data and voice communication applications forexample, will normally be installed on UE 1400 during manufacturing.Other applications could be installed subsequently or dynamically.

One software application may be a personal information manager (PIM)application having the ability to organize and manage data itemsrelating to the user of the UE such as, but not limited to, e-mail,calendar events, voice mails, appointments, and task items. Naturally,one or more memory stores would be available on the UE to facilitatestorage of PIM data items. Such PIM application would generally have theability to send and receive data items, via the wireless network 1419.In one embodiment, the PIM data items are seamlessly integrated,synchronized and updated, via the wireless network 1419, with the UEuser's corresponding data items stored or associated with a hostcomputer system. Further applications may also be loaded onto the UE1400 through the network 1419, an auxiliary I/O subsystem 1428, serialport 1430, short-range communications subsystem 1440 or any othersuitable subsystem 1442, and installed by a user in the RAM 1426 or anon-volatile store (not shown) for execution by the microprocessor 1438.Such flexibility in application installation increases the functionalityof the device and may provide enhanced on-device functions,communication-related functions, or both. For example, securecommunication applications may enable electronic commerce functions andother such financial transactions to be performed using the UE 1400.

In a data communication mode, a received signal such as a text messageor web page download will be processed by the communication subsystem1411 and input to the microprocessor 1438, which preferably furtherprocesses the received signal for element attributes for output to thedisplay 1422, or alternatively to an auxiliary I/O device 1428.

A user of UE 1400 may also compose data items such as email messages forexample, using the keyboard 1432, which is preferably a completealphanumeric keyboard or telephone-type keypad, in conjunction with thedisplay 1422 and possibly an auxiliary I/O device 1428. Such composeditems may then be transmitted over a communication network through thecommunication subsystem 1411.

For voice communications, overall operation of UE 1400 is similar,except that received signals would preferably be output to a speaker1434 and signals for transmission would be generated by a microphone1436. Alternative voice or audio I/O subsystems, such as a voice messagerecording subsystem, may also be implemented on UE 1400. Although voiceor audio signal output is preferably accomplished primarily through thespeaker 1434, display 1422 may also be used to provide an indication ofthe identity of a calling party, the duration of a voice call, or othervoice call related information for example.

Serial port 1430 in FIG. 14 would normally be implemented in a personaldigital assistant (PDA)-type UE for which synchronization with a user'sdesktop computer (not shown) may be desirable, but is an optional devicecomponent. Such a port 1430 would enable a user to set preferencesthrough an external device or software application and would extend thecapabilities of UE 1400 by providing for information or softwaredownloads to UE 1400 other than through a wireless communicationnetwork. The alternate download path may for example be used to load anencryption key onto the device through a direct and thus reliable andtrusted connection to thereby enable secure device communication. Aswill be appreciated by those skilled in the art, serial port 1430 canfurther be used to connect the UE to a computer to act as a modem.

Other communications subsystems 1440, such as a short-rangecommunications subsystem, is a further component which may provide forcommunication between UE 1400 and different systems or devices, whichneed not necessarily be similar devices. For example, the subsystem 1440may include an infrared device and associated circuits and components ora Bluetooth™ communication module to provide for communication withsimilarly enabled systems and devices. Subsystem 1440 may also be usedfor WiFi or WiMAX communications.

The embodiments described herein are examples of structures, systems ormethods having elements corresponding to elements of the techniques ofthis application. This written description may enable those skilled inthe art to make and use embodiments having alternative elements thatlikewise correspond to the elements of the techniques of thisapplication. The intended scope of the techniques of this applicationthus includes other structures, systems or methods that do not differfrom the techniques of this application as described herein, and furtherincludes other structures, systems or methods with insubstantialdifferences from the techniques of this application as described herein.

We claim:
 1. A method for handling hybrid automatic repeat request(‘HARQ’) operations at an user equipment in a wireless communicationsnetwork during transmission mode changes, the method comprising:detecting a change of a transmission modechange, the transmission modedefining at least a maximum number of transport blocks per transmissionopportunity; manipulating an HARQ process buffer; wherein the HARQprocess buffer is an uplink HARQ process buffer; and wherein an eNBprovides receiving, from an eNB, an uplink grants only grant for amaximum of a first number of transport blocks per uplink HARQ processtransmission opportunity prior to, during or both prior to and during anuplink the change of the transmission modereconfiguration in which,wherein the change of the transmission mode reduces the maximum numberof transport blocks per transmission opportunity is reduced from asecond number of transport blocks to the first number of transportblocks, the second number of transport blocks being greater than thefirst number of transport blocks; and in response to the second numberof transport blocks being greater than the first number of transportblocks, manipulating an HARQ process buffer, wherein the HARQ processbuffer is an uplink HARQ process buffer.
 2. The method of claim 1,wherein the manipulating comprises flushing the HARQ process buffer. 3.The method of claim 1, wherein said manipulating comprises flushing theHARQ process buffer only if the change of the transmission mode changeincludes a change in the maximum number of transport blocks pertransmission opportunity.
 4. The method of claim 1, wherein saidmanipulating comprises flushing the HARQ process buffer only if thetransmission mode change includes a change from a transmission mode witha maximum of one transport block per transmission opportunity to atransmission mode with a maximum of more than one transport blocks pertransmission opportunity.
 5. The method of claim 1, wherein saidmanipulating further comprises discarding only a second transport blockif the change of the transmission mode change is from a transmissionmode with a maximum of two transport blocks per transmission opportunityto a transmission mode with a maximum of one transport block pertransmission opportunity.
 6. The method of claim 1, wherein saidmanipulating further comprises discarding only a first transport blockand handling soft bits from the second transport block as the firsttransport block if the change of the transmission mode change is from atransmission mode with a maximum of two transport blocks pertransmission opportunity to a transmission mode with a maximum of onetransport block per transmission opportunity and if all soft bits on thefirst transport block have been successfully decoded.
 7. The method ofclaim 1, wherein said manipulating comprises keeping a first number oftransport blocks and initializing a second number of transport blockswhen the transmission mode change includes a change from a transmissionmode with a maximum number of transport blocks per transmissionopportunity equal to the first number to a transmission mode with amaximum of transport blocks per transmission opportunity equal to thefirst number plus the second number.
 8. The method of claim 1, furthercomprising detecting when a transport block is smaller than apredetermined size, and if not, said manipulating comprising bufferingor discarding the transport block.
 9. The method of claim 1, whereinsaid manipulating comprises flushing a transport block if the change ofthe transmission mode change involves a change in the maximum number oftransport blocks per transmission opportunity and if the transport blocksize is larger than a threshold.
 10. The method of claim 1, wherein theHARQ process buffer is a downlink HARQ process buffer.
 11. The method ofclaim 1, wherein an eNB starts new transmissions by providing uplinkgrants with new data indications when an uplink transmission mode isreconfigured.
 12. The method of claim 1, wherein an eNB starts newtransmissions by providing uplink grants with new data indications whenthe uplink transmission mode is reconfigured and a maximum number oftransport blocks per uplink HARQ process is changed.
 13. The method ofclaim 1, wherein an eNB provides uplink grants only for a maximum of afirst number of transport blocks per uplink HARQ process during anuplink transmission mode reconfiguration in which the maximum number oftransport blocks per transmission opportunity is increased from thefirst number of transport blocks to a second number of transport blocks,the second number of transport blocks being greater than the firstnumber of transport blocks.
 14. An user equipment configured forhandling hybrid automatic repeat request (‘HARQ’) operations duringtransmission mode changes comprising: a processor; and a communicationssubsystem; the processor and communications subsystem being configuredto: detect a transmission mode change, the transmission mode defining atleast a maximum number of transport blocks per transmission opportunity;manipulate an HARQ process buffer; and to discard only a first transportblock and handling soft bits from the second transport block as thefirst transport block if the transmission mode change is from atransmission mode with a maximum of two transport blocks pertransmission opportunity to a transmission mode with a maximum of onetransport block per transmission opportunity and if all soft bits on thefirst transport block have been successfully decoded.
 15. The userequipment of claim 14, wherein the manipulating comprises flushing theHARQ process buffer.
 16. The user equipment of claim 14, furtherconfigured to flush the HARQ process buffer only if the transmissionmode change includes a change in the maximum number of transport blocksper transmission opportunity.
 17. The user equipment of claim 14,further configured to flush the HARQ process buffer only if thetransmission mode change includes a change from a transmission mode witha maximum of one transport block per transmission opportunity to atransmission mode with a maximum of more than one transport blocks pertransmission opportunity.
 18. The user equipment of claim 14, furtherconfigured to discard only a second transport block if the transmissionmode change is from a transmission mode with a maximum of two transportblocks per transmission opportunity to a transmission mode with amaximum of one transport block per transmission opportunity.
 19. Theuser equipment of claim 14, further configured to keep a first transportblock and initialize a second or subsequent transport block when thetransmission mode change includes a change from a transmission mode witha maximum of one transport block per transmission opportunity to atransmission mode with a maximum of more than one multiple transportblocks per transmission opportunity.
 20. The user equipment of claim 14,further configured to detect when a transport block is smaller than apredetermined size, and if not, said manipulating comprising bufferingor discarding the transport block.
 21. The user equipment of claim 14,further configured to flush a transport block if the transmission modechange involves a change in the maximum number of transport blocks pertransmission opportunity and if a size of the transport block is largerthan a threshold.
 22. A user equipment (UE), comprising: at least onehardware processor; and a non-transitory computer-readable storagemedium coupled to the at least one hardware processor and storingprogramming instructions for execution by the at least one hardwareprocessor, wherein the programming instructions, when executed, causethe UE to perform operations comprising: detecting a change of atransmission mode, the transmission mode defining at least a maximumnumber of transport blocks per transmission opportunity; receiving, froman eNB, an uplink grant for a maximum of a first number of transportblocks per transmission opportunity prior to, during or both prior toand during the change of the transmission mode, wherein the change ofthe transmission mode reduces the maximum number of transport blocks pertransmission opportunity from a second number of transport blocks to thefirst number of transport blocks, the second number of transport blocksbeing greater than the first number of transport blocks; and in responseto the second number of transport blocks being greater than the firstnumber of transport blocks, manipulating an hybrid automatic repeatrequest (HARQ) process buffer, wherein the HARQ process buffer is anuplink HARQ process buffer.
 23. The UE of claim 22, wherein themanipulating comprises flushing the HARQ process buffer.
 24. The UE ofclaim 22, wherein the manipulating comprises flushing the HARQ processbuffer if the change of the transmission mode includes a change in themaximum number of transport blocks per transmission opportunity.
 25. TheUE of claim 22, wherein the manipulating further comprises discarding asecond transport block if the change of the transmission mode is from atransmission mode with a maximum of two transport blocks pertransmission opportunity to a transmission mode with a maximum of onetransport block per transmission opportunity.
 26. The UE of claim 22,wherein the manipulating further comprises discarding a first transportblock and handling soft bits from the second transport block as thefirst transport block if the change of the transmission mode is from atransmission mode with a maximum of two transport blocks pertransmission opportunity to a transmission mode with a maximum of onetransport block per transmission opportunity and if soft bits on thefirst transport block have been successfully decoded.
 27. The UE ofclaim 22, further comprising detecting when a transport block is smallerthan a predetermined size, and if not, said manipulating comprisingbuffering or discarding the transport block.
 28. The UE of claim 22,wherein said manipulating comprises flushing a transport block if thechange of the transmission mode involves a change in the maximum numberof transport blocks per transmission opportunity and if the transportblock size is larger than a threshold.
 29. A non-transitorycomputer-readable medium storing instructions which, when executed,cause a computing device to perform operations comprising: detecting achange of a transmission mode, the transmission mode defining at least amaximum number of transport blocks per transmission opportunity;receiving, from an eNB, an uplink grant for a maximum of a first numberof transport blocks per transmission opportunity prior to, during orboth prior to and during the change of the transmission mode, whereinthe change of the transmission mode reduces the maximum number oftransport blocks per transmission opportunity from a second number oftransport blocks to the first number of transport blocks, the secondnumber of transport blocks being greater than the first number oftransport blocks; and in response to the second number of transportblocks being greater than the first number of transport blocks,manipulating an hybrid automatic repeat request (HARQ) process buffer,wherein the HARQ process buffer is an uplink HARQ process buffer. 30.The non-transitory computer-readable medium of claim 29, wherein themanipulating comprises flushing the HARQ process buffer.
 31. Thenon-transitory computer-readable medium of claim 29, wherein themanipulating comprises flushing the HARQ process buffer if the change ofthe transmission mode includes a change in the maximum number oftransport blocks per transmission opportunity.
 32. The non-transitorycomputer-readable medium of claim 29, wherein the manipulating furthercomprises discarding a second transport block if the change of thetransmission mode is from a transmission mode with a maximum of twotransport blocks per transmission opportunity to a transmission modewith a maximum of one transport block per transmission opportunity. 33.The non-transitory computer-readable medium of claim 29, wherein themanipulating further comprises discarding a first transport block andhandling soft bits from the second transport block as the firsttransport block if the change of the transmission mode is from atransmission mode with a maximum of two transport blocks pertransmission opportunity to a transmission mode with a maximum of onetransport block per transmission opportunity and if soft bits on thefirst transport block have been successfully decoded.
 34. Thenon-transitory computer-readable medium of claim 29, further comprisingdetecting when a transport block is smaller than a predetermined size,and if not, said manipulating comprising buffering or discarding thetransport block.
 35. The non-transitory computer-readable medium ofclaim 29, wherein said manipulating comprises flushing a transport blockif the change of the transmission mode involves a change in the maximumnumber of transport blocks per transmission opportunity and if thetransport block size is larger than a threshold.